CXH-2379: fix grant/revoke idempotency for DDL-based engines - #151

Validation-query "no rows" now wraps ErrQueryAffectedZeroRows so the
provisioning layer's errors.Is check reports GrantAlreadyExists /
GrantAlreadyRevoked instead of failing the task. DDL dialects (e.g. Db2)
whose GRANT/REVOKE raise an error rather than affecting rows can only
signal prior state through validation_queries, which previously landed on
the failing path.

Adds regression tests driving Grant/Revoke end-to-end over in-memory
sqlite for both the already-applied (idempotent) and apply cases.

A validation query returning no rows now maps to ErrQueryAffectedZeroRows
(reported as GrantAlreadyExists / GrantAlreadyRevoked) only on DDL-based
engines (Db2), which don't report rows-affected. Other engines keep using
validation queries as existence preconditions that fail loudly, so a grant
against a missing user or role is no longer silently reported as success.
This also restores the grant_replace abort behavior on those engines: a
replaced-grant revoke whose validation returns no rows returns a plain
error instead of the sentinel, so GrantReplaced is not emitted.

Document the engine-specific ValidationQueries semantics and add a test
covering the non-DDL loud-failure path.

Mirror TestGrant_ValidationNoRowsOnNonDDLEngineFailsLoudly on the revoke
path: on a non-DB2 engine, a revoke validation query returning no rows is
a failed precondition, so Revoke returns an error with nil annotations
rather than GrantAlreadyRevoked. Pins the false branch of
validationNoRowsMeansIdempotent() for RunProvisioningQueriesWithExecutor.

- Extract shared runValidationQueries helper so the grant and revoke
  validation loops stop drifting (the copies had diverged on result.Close).
- Warn in the ValidationQueries doc comment that DDL-engine authors must not
  reuse validation_queries as an existence precondition, since a no-rows result
  is reported as idempotent success and would mask real failures.
- Preserve annotations returned by RunGrantProvisioning in the already-exists
  branch so a GrantReplaced from a committed grant_replace revoke survives.

On the transactional grant path, RunGrantProvisioning returns the
zero-rows sentinel before commit, so the deferred rollback undoes any
grant_replace revoke. Grant reused those annotations, reporting
GrantReplaced for a removal the database no longer reflects. Keep the
returned annotations only on the no_transaction path, where the replace
already committed; otherwise return a fresh GrantAlreadyExists.

Adds regression tests for both the rolled-back (no GrantReplaced, old
grant survives) and committed (GrantReplaced, old grant gone) paths.

On Db2 a grant_replace revoke whose validation query returns no rows swallows
ErrQueryAffectedZeroRows and still reports GrantReplaced: the old grant is
already gone, which is the state a replace aims for. Document this at the guard,
cover it with a DB2 test, and add a validation_queries section to docs/db2.md
warning against using them as existence preconditions on Db2.

Oracle GRANT/REVOKE are DDL like Db2: an already-applied REVOKE raises
ORA-01951 (and re-GRANT succeeds without affecting rows), so the
validation query is the only zero-effect signal. Add Oracle to
validationNoRowsMeansIdempotent() so validation 'no rows' maps to
GrantAlreadyExists / GrantAlreadyRevoked instead of failing the task.

Verified live against Oracle XE 21c (grant/re-grant -> GrantAlreadyExists,
revoke/re-revoke -> GrantAlreadyRevoked, no ORA-01951, revoke DDL skipped).
Adds an engine-gate regression test and updates the ValidationQueries doc.

Replace os.Exit(1) in main.go with exit.LogExit(err) so an auth failure exits
with the mapped gRPC status code instead of a bare 1, letting the CI sync-test
auth-error check actually assert.

…nt-and-revoke-idempotency-for-ddl-based

Pairs with the exit.LogExit change: Validate wrapped the ping error plainly, so
exit mapped auth failures to Unknown(2). database.AuthError maps SQLSTATE class 28
(Postgres/Redshift/Vertica/etc.) and MySQL 1045 to codes.Unauthenticated.

…evoke

On a DDL engine a revoke whose validation_queries return no rows short-
circuits before any revoke runs. RunRevokeProvisioning still ran the
principal_exists_check probe, so a mistyped principal_id (validation and
probe both empty) falsely reported a still-present principal as deleted,
contradicting the PrincipalExistsCheck contract.

Add a distinct ErrValidationNoRows sentinel (wrapping ErrQueryAffectedZeroRows
so idempotency reporting is unchanged) and skip the exists probe when the
zero-rows result came from validation rather than the revoke queries running.

Also: reword the grant_replace zero-rows comment to cover both sentinel
sources (not just DDL), include the failing query in the loud validation
error, and link docs/provisioning.md from README. Adds a regression test.